1. Field of the Invention
This invention relates to an anti-tamper system, i.e. a system that makes it difficult for a hacker to modify a piece of software. The system employs a unique automated analysis in order to achieve a system of high performance and security with little user configuration or intervention
2. Description of the Prior Art
The use of computer software applications is ubiquitous in modern life. They can provide fun and enjoyment to those using them, and can automate complicated procedures allowing us to do things we could not otherwise do. They can enable communication, and can aid in the dissemination and visualisation of complex information. In all of these capacities, good software is a valuable commodity for which consumers are willing to pay.
In turn, the burgeoning software industry has invested, and continues to invest, heavily in the development of such products to meet this market demand.
To protect this investment, developers and publishers insert protections into the software to ensure that only authorised persons are able to use it and that others cannot gain a competitive advantage by analysing it to obtain secrets, or by modifying it to change its behaviour.
However, there are a number of individuals (hackers) who are skilful at reverse-engineering and modifying such software. Their goals are to circumvent the inserted protections in order to, for example, remove “trial” limitations, access secret cryptographic information, and cheat in online competitions. These “hacked” versions are then distributed, usually on the internet, to potentially many thousands of users, with obvious impact on the revenues of software companies.
It is the goal of an “anti-tamper” system to prevent or at least make it very difficult for hackers to modify a piece of protected commercial software.
The methods employed by anti-tamper systems broadly fall into two main areas.
First, the code can be obfuscated. An obvious precursor to modifying a piece of software is understanding how it works—sometimes to a limited extent. A number of patents describe methods to obfuscate application code, in order to make this process of understanding difficult. It is important to note that the obfuscated code may be run in its obfuscated state or it may have to be de-obfuscated before being run, as is the case when code encryption is used. Both cases have the problem that, if a hacker can understand the obfuscation process, the protection is rendered ineffective. Determining the difficulty that the hacker has, and hence the strength of the protection system, is not easy.
The second method, and the one used in the present invention, is to verify that the application has not been tampered with, where tampering includes code and/or data modifications, changes to the execution environment, or any other measure which ultimately changes the behavior of the application. We call these points of verification ‘integrity checks’.
For example, during its normal running, an application might check the integrity of its own code. A particular area of the application code might use a check summing algorithm to verify that another (target) area of code has not been modified. Through extrapolation of such a checking approach, an interconnected web of checks (a topology) can be constructed. The intention being that any modification to the application code will be detected and defensive action can be taken. These code integrity checks can be injected into an existing program either manually or automatically.
Chris Crawford released a paper into the public domain that described using checksums to empower a self-checking system to prevent hacking. He had previously employed this system in 1990 to protect Patton Strikes Back, and may have used earlier to protect Trust and Betrayal in 1988. Although the original paper is difficult to find, Crawford describes the self-checking system used in Patton Strikes Back in his 2003 book, “Chris Crawford on Game Design”, which makes explicit mention of checks which check each other to form a large “web of checks”, a core concept used by all self-checking protection systems since then. Crawford also describes the use of variance to disguise checks and any responses.
There have been a number of published variants of this basic approach.
Another form of integrity check involves using techniques which can reveal the presence of debugging/hacking tools, or even frustrate their use such that a hacker cannot easily deploy such tools against a protected program. This type of integrity check is typically called an anti-debug measure. These can also be injected into an existing program either manually or automatically.
There are significant problems in such approaches which we address with our approach by the introduction of a new paradigm and technology.
Since the integrity checking is being performed at run-time, there are possible performance penalties for the protected application: checks run at an inappropriate time can lead to a poor user experience. To minimise this risk, developers tend to add a small number of such checks. In turn, this leads to less protective strength; it is easier for hackers to discover, understand, and remove all the checks. Furthermore, no code self-checking scheme devised so far addresses the problem of when checks are performed compared to when the checked code is executed. If this is left to chance, it may be extremely easy for a hacker to modify the code he/she desires, have it execute, and then return it to its original state.
Balancing the related aspects of number of checks, their runtime performance, and the resulting protection strength is therefore key to a successful application of an integrity verifying protection scheme particularly if little user intervention is required. Furthermore, it is essential that the scheme take into account the runtime sequence of application code execution.